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Who  Are  We  and  Why  Do  We  Care 
About  CMMI®  Transition? 

Who? 

•  SuZ:  Researcher  in  technology  transition  practices  who  also 
has  extensive  experience  building  and  deploying  CMM®s 

•  Maggie:  Process  improvement  specialist  working  with  multiple 
models  with  multiple  organizations;  SCAMPI  Lead  Assessor 

Why  do  we  care? 

•  SW-CMM  is  the  first  major  SEI  technology  to  be  “replaced”  by 
a  subsequent  SEI  technology 

•  We  don’t  want  to  see  organizations  adopting  CMMI®  making 
mistakes  we’ve  already  learned  from  in  SW-CMM®  adoption 

•  We  want  to  see  organizations  transitioning  from  SW-CMM® 

CMMI®  make  as  easy/effective  a  transition  as  possible 
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Who  are  YOU? 

How  many  (raise  hands  please!) 

•  Are  currently  involved  in  SW-CMM®  based  improvement? 

•  CM  Ml® -based  improvement? 

•  Improvement  using  another  model/approach? 

How  many  have  been  working  in  model-based  improvement.... 

•  Less  than  1  year 

•  1-3  years 

•  3-10  years 

•  >  10  years 

How  many  have  been  working  with  CMMI®-based  improvement 

•  Less  than  1  year 

•  1-3  years 
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Why  are  YOU  Interested  in 
(possible)  Transition  to  CMMI? 
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Context  for  TTP  Involvement  in 
SEI  Technologies 

The  SEI’s  goal  is  to  institutionalize  new  and  improved 
practices  in  the  acquirer  and  developer  communities*  This 
requires  corporate  competence  in  at  least  two  areas: 


technically  excellent  solutions  to  relevant  software 
engineering  problems,  and 

impact-producing  strategies  for  technology  transitiorT 


*  SEI  Strategic  Plan,  FY2003 


TTP  Focus  and  our 
focus  in  this  workshop 
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What  We  Will  NOT  Be  Dealing 
with  Today... 

Content  or  Structure  of  CMMI® 

•  Information  resources  at  back  of  tutorial  materials 
provide  links  to  lots  of  information  related  to 
structure/content 

•  Other  presentations/tutorials  at  this  conference  will  be 
covering  structure/content 
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What  We  Will  Be  Dealing  With 


•  Understanding  the  goals  for  adoption 

•  Understanding  the  goals  of  the  different  roles  involved  in  the 
transition  and  how  they  relate 

•  Understanding  the  characteristics  of  the  technology  (that  would  be 
CMMI!) 

•  Understanding  what  will  be  needed  to  make  the  technology  “work” 

•  Identifying  and  mitigating  the  different  types  of  risks  identified  as 
part  of  understanding  all  the  above 
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The  TTP  Mission 


How? 


Consulting 

Technologies 

Education 


To:  stakeholders 
inside  and  outside 
the  SEI 


To  ensure  and  provide  the 
SEI’s  core  competence  in 
“impact-producing  strategies  for 
technology  transition”. 
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Where  does  TTP  fit  within  the 
SEI? 

TTP  is  the  “home”  of  the  best  practices  for  the  SEI’s  core 
competency,  software  technology  transition,  and  resides  within 
the  Technology  Transition  Services  Directorate 

TTP  supports  all  the  SEI  technical  initiatives,  by  providing 

•  Consulting  for  the  different  transition  roles  involved  in  an  SEI 
technology 

•  Adaptable  workshops,  processes,  and  other  practices  ready  to 
be  tuned  to  the  needs  of  a  particular  technology  or  transition  role 

TTP  is  active  in  evolving  the  body  of  knowledge  for  technology 
transition  through  research,  application  of  best  practice,  and  sharing 
of  lessons  learned  with  the  SEI  and  technology  transition 
communities 
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Technology  +  Transition  =  Impact 


Summary  of  the  SEI’s  technology 
maturation/transition  approach 


©  2002  by  Carnegie  Mellon  University 


Version  1.0 


page  12 


CarnegieMellon 

Software  Engineering  Institute 

Common  Misconceptions  about 
“Transition” 


Activities  addressing  transition  aren’t  needed  until  the 
technology  is  done 

Planning  for  Transition  starts  in  the  Create  stage.  Early 
Majority  piloting  and  Whole  Product  development 
culminate  in  the  Apply  stage.  Monitoring  and 
refinement  happen  in  the  Amplify  stage.  Waiting  until 
the  end  of  technology  development  to  begin  transition 
activities  is  expensive. 


Think  this... 


Rather  than  ... 
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The  TTP  Toolkit 


Create 


Mostly  tools  for  technology 
developers 


Apply 


Amplify 


Groundbreaking  workshop 
Transition  Baseline  Review 
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The  TTP  Toolkit 


Create 


Mostly  tools  for  technology 
deployers  and  adopters 


Apply 


Amplify 
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The  TTP  Toolkit 

Mostly  tools  for  transition 
communities  &  technology 
developers 


Create 


Transition  Progress  Review 

Transition  Skills  Development 

Professional  Certificate 
Program 
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Context 

The  next  set  of  slides  are  written  from  the  viewpoint  of  what 
CMMI®  is  like  (from  a  transition  viewpoint)  to  someone  who 
is  not  currently  active  in  improvement.... 

•  Many  of  the  same  things  could  have  been  said  when 
adopting  SW-CMM® 

•  The  “radicalness”  of  the  change  will  be  less  when 
moving  from  one  CMM®-based  improvement  context  to 
another 
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Why  Look  at  the  Adoption  of  the 
CMMI®  as  a  Technology 
Transition? 

CMMI®  is  a  technology--a  process  technology,  and  what's 
more,  it's  radical  if  you’ve  never  been  involved  in  model- 
based  improvement  before 

-  "Radical  innovation  is  the  process  of  introducing 
something  that  is  new  to  the  organization  and  that 
requires  the  development  of  completely  new 
routines,  usually  with  modifications  in  the 
normative  beliefs  and  value  systems  of 

organization  members. "  —  Nord  and  Tucker,  Routine 
and  Radical  Innovations,  1987 
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What  do  you  think? 

If  you’re  new  to  model-based  improvement: 

•  What  do  you  think  (based  on  your  current  knowledge  of  CMMI) 
that  CMMI®  adoption  will  require  in  terms  of: 

-  development  of  new  routines  (procedures)? 

-  modifications  in  the  norms,  beliefs,  and  values  of 
organization  members? 

If  you’ve  been  using  another  model  as  your  improvement  base, 
how  different  are  your  answers? 


-  I’d  expect  you  to  still  have  to  develop  “new 
routines” 

-  I  would  expect  that  many  of  the  norms,  beliefs, 
and  values  are  similar  between  another  model 
(i.e.  SW-CMM®)and  CMMI® 
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A  few  possibilities  of  changes  in  norms, 
beliefs,  and  values  of  key  roles  in  a 
“typical”  organization  beginning  CMMI®- 
based  improvement . 
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What  will  CMMI®  mean  to 
Managers/Practitioners 

Focus  of  behavior  changes  for  CMMI®  Maturity  Level  2: 

•  Commitment: 

-  understanding  who  the  stakeholders  are  and  achieving 
common  understanding  with  them  of  the  project's 
scope/requirements 

-  moving  from  accepting  changes  without  adequate  impact 
analysis  to  negotiated  changes  based  on  impact  ($,time) 

•  Control: 

-  management  moves  from  after-the-fact  corrective  action  to 
measurement-focused,  more  proactive  controls  throughout 
the  program 

-  requirements  are  the  fundamental  basis  for  planning  and 
control 

-  risk  management  is  explicitly  used  throughout  the  systems 
and  software  engineering  disciplines 
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What  will  CMMI®  mean  to 
Managers/Practitioners-2 

•  Communication: 

-  management  focus  moves  from  “communication  is  an 
extra  step  in  the  process”  to  “communication  is  vital  to 
keeping  the  process  going” 

-  notion  of  stakeholders  as  the  base  for  communication 
expands  the  scope  of  communication  activities 
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Senior  Managers 

MORE.... 

•  focus  on  requirements  as  the  basis  for  planning  and  changes 

•  early  information  on  risks  and  problems 
LESS.... 

•  firefighting 

•  making  commitments  without  adequate  impact  analysis 

•  rewarding  of  firefighting  vs.  fire  prevention  behaviors 
Resulting  in.... 

•  fewer  letters/phone  calls  from  unsatisfied  external  customers 
on  systems  issues  l.e.  fewer  product  quality  complaints. 

•  less  shipping  of  engineers  to  the  field  “until  the  problems  are 
solved” 

•  more  visibility  into  ability  to  meet  system  schedules  and 
budgets  l.e.  forecasting  and  estimation. 
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Program  Managers 

MORE... 

•  involvement  in  understanding  system  and  software 
requirements  and  their  impact  on  the  system 

•  routine  visibility  into  project  progress 

•  visibility  into  subsystem  subcontracts 

•  insight  into  subsystem  subcontractor  risks 

LESS/FEWER.... 

•  large,  unmanageable  tasks 

•  reason  or  ability  to  make  un-negotiated  commitments 

•  accepting  requirements  changes  without  adequate 
impact  analysis 
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Functional  Managers 

MORE... 

•  requirements-based  planning 

•  information  available 

•  communication  about  potential  problems  EARLY 

•  focus  on  negotiating  change,  rather  than  accepting  all 
proposed  changes  without  impact  analysis 

•  focus  on  consistent  inclusion  of  stakeholders  throughout 
proposals 

•  scheduled  communication  of  progress  and  result 
reporting  throughout  the  project 

•  training  in  project  management 

•  knowledge  about  “how  things  work”  available  to 
engineers 
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Functional  Managers-2 

LESS/FEWER.... 

•  firefighting 

•  willingness  to  accept  commitments  that  are 
known(because  of  data!!!!)  to  be  impossible  to  meet 

•  reliance  on  “single  point  failures” 

•  reliance  on  large,  undifferentiated  WBS’  as  management 
focus 

•  daily  “corrective  action”  meetings  late  in  the  project 
(firefighting) 

•  reliance  on  primarily  intuition-based  management 
practices 
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Practitioners 

MORE.... 

•  requirements-based  estimation 

•  information  available  earlier 

•  opportunity  to  surface  potential  problems  early 

•  focus  on  negotiating  change,  rather  than  accepting  all 
proposed  changes  without  impact  analysis 

•  information  on  "how  to  get  things  done"  in  a  consistent  fashion 
LESS/FEWER.... 

•  Overtime/working  weekends 

•  reliance  on  intuition  for  engineering  estimates 

•  demand  to  accept  commitments  that  are  known(because  of 
data!!!!)  to  be  impossible  to  meet 

•  reward  for  fixing  problems  late  that  should  have  been  surfaced 
early! 

•  daily  “corrective  action”  meetings  late  in  the  project 
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Support  Groups 

Human  Resources: 

•  better  trained  work  force 

•  higher  morale  in  work  force 

Marketing: 

•  better  estimates  of  product  costs  --  not  necessarily 
“cheaper”,  but  more  accurate! 

Contracts/Subcontracts: 

•  better  criteria  for  selecting  subsystem  subcontractors 

•  more  insight  into  risks  with  subsystem  subcontractors 
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But  getting  there  means 
CHANGING! 

...and  we  know  how  easy  THAT  is! 
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From  the  Change  Agent's 
Viewpoint 
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From  the  Users'  Viewpoint 
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From  the  Executive's  Viewpoint 


New  technologies 

•  are  hard  to  select 
efficiently/effectively 

•  are  hard  to  deploy 
efficiently/effectively 

•  are  (too)  soon  replaced  by 
even  newer  technologies 
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Role  of  TTP  with  CMMI® 


Work  with  CMMI®  team  to  monitor/refine  CMMI®  transition 
strategy 

Apply  TTP  practices  and  techniques  to  enabling  and  monitoring 
CMMI®  transition: 

•  Multiple  instances  of  “what  works,  what’s  needed”  workshops 
have  been  facilitated  by  TTP  and  those  trained  by  TTP 

•  “Are  You  Prepared  for  CMMI®?”  Crosstalk  article/conference 
tutorial  to  help  build  awareness  of  techniques  to  facilitate 
transition  to/adoption  of  CMMI® 

•  TTP  is  piloting  selected  transition  practices  from  TRAIL  (TTP’s 
framework  for  transition  management  practices)  with  an  Army 
Systems  Engineering  Division 

-  Transition  from  SW-CMM®  to  CMMI® 

-  Expanding  improvement  effort  to  include  systems 
engineering  and  other  SED  stakeholders 
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transitioning  to  a  new 

E^eGitU^kOiOig^^inizations  are  using  IDEAL®-based 
practices,  we  still  see  many  of  these  problems  in  the  field: 

Poor  fit  between  maturity  of  the  technology  and  characteristics  of 
the  adopters 

•Important  issue  for  CMMI® 

Insufficient/inappropriate  support  mechanisms  defined  and/or 
implemented 

•Will  pay  special  attention  to  this  in  this  tutorial 

“Train  it  and  they  will  adopt”  mentality 

•Too  often  training  is  seen  as  the  only  support  mechanism 
needed  to  achieve  adoption 

Insufficient  transition  agent  skills/knowledge 

•The  range  of  skills/knowledge  needed  by  transition  agents  is 
broader  than  most  people  think 

TRAIL  is  one  way  (not  the  only  one)  to  implement  IDEAL®  practices 
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A  Framework  for 
Technology  Transition 

d?era99®f  of  theTramftJork 

•  effective,  timely  adoption  of 
technology 

•as  defined  by  developer 
•as  defined  by  acquirer 
•as  defined  by  deployer 
•as  defined  by  adopter 

Other  Objectives 

•  improve  understanding  of  technology 
transition  management 

•as  defined  by  a  transition 
community 
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Key  Elements  in  Successful 
Transition 

•  Understanding  the  goals  of  the  different  roles  involved  in  the  transition  and 
how  they  relate 

-  Understanding  the  target  adoption  population  (market)  for  the 
technology 

-  Value  networks 

•  Understanding  the  characteristics  of  the  technology 

-  What  problems  is  it  intended  to  solve?  Are  those  the  ones  we’re  using 
it  for? 

-  How  well  does  it  match  the  needs  of  adopters  who  have  a  need  to 
solve  those  problems? 

-  How  “transitionable”  is  the  technology? 

•  Understanding  what  will  be  needed  to  make  the  technology  “work”  for 
different  types  of  adopters 

-  Transition  mechanisms  for  the  technology 

-  Work  practice  and  other  changes  in  the  adopting  organization 

•  Identifying  and  mitigating  the  different  types  of  risks  identified  as  part  of 
understanding  all  the  above 
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Building  a  Transition  Strategy  for  CMMI 

Analyzing  Your  Existing  PI  Infrastructure  for  Potential  Reuse 

Summary/Where  Will  You  Go  From  Here? 
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Concepts  that  Apply  to  Any 
Technology  Transition 

Each  transition  is  highly  situational  and  its  strategy  will  be 
unique  to  that  situation  and  context,  however,  some  basic 
concepts  can  be  applied  in  generating  that  strategy: 

•  Multiple  dimensions  have  to  be  addressed 
simultaneously  to  achieve  success,  not  just  the 
technology  content 

•  Different  audiences  respond  differently  as  they  are 
introduced  to  the  technology 

•  Acceptance  of  a  new  technology  does  not  happen  in  a 
linear,  predictable  fashion,  no  matter  how  pretty  the 
charts  look! 
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Concepts  that  Apply  to  Any 
Technology  Transition-2 

•  There  are  both  different  "levels  of  diffusion"  —breadth  of 
technology  acceptance,  and  "levels  of  use  (or  infusion)"  - 
-  degree  to  which  the  technology  becomes  embedded  in 
the  organization's  governing  and  social  practices 

•  Different  "mechanisms"  are  useful  at  different  points  in 
the  transition  to  address  different  implementation  issues 
with  different  audiences 

•  Most  organizations  are  very  poor  at  transferring  what 
they've  learned  from  one  technology  transition  effort  to 
another 

The  rest  of  this  section  will  focus  on  relieving  some  of  these 
issues. 
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Factors  In  Considering  Adopting 
Complex  Technology 

Primary  reasons  organizations  delay  investing  in  new 
innovations . 

•  prior  technology  drag-legacy  systems  and  work  procedures 
based  on  them 

•  irreversibility  of  investments-short  "useful  life"  for  large 
amount  of  money! 

•  sponsorship-getting  and  keeping  it  are  a  challenge  for 
dynamic  organizations 

•  expectations-what  the  technology  can  deliver  vs.,  what  is 
promised/expected 

(adapted  from  Fichman  and  Kemerer, ,  “Adoption  of  Software  Engineering  Process  Innovations:  The  Case  of  Object 
Orientation,” Sloan  Management  Review,  Winter  1993,  pp.  7-22.) 

Which  of  the  above  affect  your  consideration  of  transitioning  to 
CMMI? 
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Understanding  Your  Audience  for 
the  Transition 

Which  roles  in  your  organization  will  need  to  change 
something  in  their  behavior/attitudes/values  to  adopt  CMMI? 
What  things  make  these  groups  more  or  less  likely  to 
change? 
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Different  "Adopter  Types"  Move 
Through  Adoption  at  Different 
Speeds 

Depending  on  many  factors,  early  adopters  for  one  type  of 
technology  could  be  late  majority/laggards  for  another! 
Where  are  you  with  regard  to  major  process  changes? 


Innovators 

Late 

Early  1 

Early  “l"1*  1 

Adopters 

Majority  Laggards 

Source:  Rogers,  Everett.  Diffusion  of  Innovation,  1995. 
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Innovators 

Gatekeepers  for  any  new  technology 

Appreciate  technology  for  its  own  sake 

Appreciate  architecture  of  technology 

Will  spend  hours  trying  to  get  technology  to  work 

Very  forgiving  of  poor  documentation,  slow  performance, 
incomplete  functionality,  etc. 

Helpful  critics 
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Early  Adopters 

Dominated  by  a  dream  or  vision 

Focus  on  business  goals 

Usually  have  close  ties  with  “techie”  innovators 

Match  emerging  technologies  to  strategic  opportunities 

Look  for  breakthrough 

Thrive  on  high  visibility,  high  risk  projects 

Have  charisma  to  generate  buy-in  for  projects 

Do  not  have  credibility  with  early  majority 
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Early  Majority 

Do  not  want  to  be  pioneers  (prudent  souls) 

Control  majority  of  budget 

Want  percentage  improvement  (incremental,  measurable, 
predictable  progress) 

Not  risk  averse,  but  want  to  manage  it  carefully 
Hard  to  win  over,  but  are  loyal  once  won 
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Late  Majority 

Avoid  discontinuous  improvement  (revolution) 

Adopt  only  to  stay  on  par  with  the  rest  of  the  world 

Somewhat  fearful  of  new  technologies 

Like  pre-assembled  packages  with  everything  bundled 
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Laggards 

“Nay  sayers” 

Adopt  only  after  technology  is  not  recognizable  as  separate 
entity 

Constantly  point  at  discrepancies  between  what  was 
promised  and  what  is 


©  2002  by  Carnegie  Mellon  University 


Version  1.0 


page  48 


CgrnegieMeltoii 

Software  Engineering  Institute 


Beyond  Understanding  Adopter  Categories 


Value  Networks  are  a 
way  to  start  looking  at 
the  exchanges  that 
need  to  occur  between 
different  roles  within  a 
“marketplace” 

•  Example:  a  value 
network  for  INTRo, 
an  SEI  technology 
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Adopters  Aren’t  the  Only  Roles 
with  Different  Issues 


Technology  Developer 

Technology  Acquirer 

Technology  Deployer — transition 
agents 

Technology  Adopter 


Transition  Communities 
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Key  Roles  in  Technology 
Transition-1 

Technology  developers:  those  who  create  new  technologies 
for  use  by  specific  or  general  populations. 

•  Examples  of  technology  developers  include  SEI  initiatives, 
DoD  S&T  organizations,  or  commercial  product  innovation 
teams. 

Technology  acquirers:  those  who  determine  which 
technologies  will  be  used  to  support  their  own  system 
development  efforts. 

•  Examples  of  technology  acquirers  include  individual 
acquisition  program  offices  and  corporate  business  units. 
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Key  Roles  in  Technology 
Transition-2 

Technology  deployers:  the  organization  or  individual 
facilitating  the  adoption  of  one  or  more  technologies  into  a 
particular  context 

•  Examples  of  technology  deployers  include  SEI  Transition 
Partners  and  military  organizations  like  STSC  who  are 
mandated  to  support  technology  adoption  for  particular 
communities. 

•  Transition  agents  are  deployers  who  (generally)  are 
interested  in  deploying  more  than  one  technology  into 
more  than  one  context  -  their  specialty  is  transition 
issues  as  much  or  more  than  the  technologies 
themselves 
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Key  Roles  in  Technology 
Transition-3 

Technology  adopters:  the  organization  or  group  who  will 
actually  be  using  a  new  technology. 

•  Examples  include  warfighter  units  in  the  military, 
manufacturing  personnel  using  new  tooling,  or  an 
organization  adopting  a  new  maturity  model. 

Transition  community:  a  mix  of  developers,  deployers, 
acquirers,  and/or  adopters  who  have  a  common  interest  in 
moving  a  particular  technology  forward  in  its  maturation 
and/or  adoption. 

•  Examples  of  these  communities  include  a  geographic 
region  interested  in  CMMI®  adoption,  or  an  interest 
group  within  a  particular  technology  area  (eg  information 
security)  who  are  attempting  large-scale  adoption  of  a 
particular  technology  quickly  and  effectively  across  their 
defined  community. 
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Understanding  Some  Major  Shifts 


Source:  Patterson  &  Conner,  “Building  Commitment  to  Organizational  Change”,  1982. 
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Different  Parts  of  the 
Organization  Learn  at  Different 
Rates 

....because  of  their  adoption  inclinations,  time  available  to  pay 
attention  to  the  new  technology,  management  direction  --  there 
are  lots  of  factors  that  can  impact  how  quickly  one  segment  of 
the  organization  adopts  vs.  another 

What  happens  if  the  practitioners  adopt  early  and  quickly,  and 
program  management  doesn't  have  time  to  pay  attention  and 
adopts  more  slowly? 
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Enabling  Movement  From  One 
Stage  to  Another  through 
Transition  Mechanisms 

Innovators  and  Early  Adopters  will  tend  to  "make  their  own" 
transition  mechanisms  and  make  do  with  what's  available 
from  the  technology  producer; 

Early  and  Late  Majority  adopters  expect  many  of  these 
mechanisms  to  be  readily  available  for  them  to  acquire 
without  development. 
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More  Detail  on  Transition 
Mechanisms 

The  transition  mechanisms  that  follow  fulfill  two  purposes: 

•  for  the  technology  producer  (i.e.  the  CMMI®  Product  Team), 
many  of  the  mechanisms  in  Contact,  Awareness,  and 
Understanding  are  used  in  their  marketing  kits 

•  for  the  technology  adopter,  technology  producer  materials 
need  to  be  adapted  to  help  "sell"  the  technology  to  the 
intended  users 

Note  that  not  all  of  these  are  actually  "products";  some  of  them 
are  events  or  activities 

These  are  a  general  set  of  mechanisms  that  could  be  used  in 
your  organization;  which  ones  are  right  for  you  depend  on  your 
organization's  context  and  culture 
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Tools  for  Contact  and  Awareness 

Communication  Devices 
"Elevator  speech" 

Standard  45  minute  pitch  -  road  show 
FAQ 

Magazine  articles 
Conference  briefings 

Flash  cards  with  objectives,  benefits,  URL,  etcA 

Web  site  devoted  to  the  technology,  with  links  and  dialogue 

Successful  ROI  stories,  case  studies 

Focus  on  concept,  not  the  buzzword 

Executive  summary  of  policy 
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Understanding 

Communication  and  Education 
One-day  seminars,  symposia  for  various  vendors 
Detailed  case  studies 
Technical  brief 

Identify  and  authorize  champions 

Identify  stakeholder  roles,  responsibilities,  and 
interrelationships 
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Trial  Use 

Question  to  consider:  How  big  do  you  need  to  be  to  consider 
pilots?  How  do  small  organizations  conduct  pilots? 

Pilot  Programs 

Carefully  identify  a  couple  of  focused  pilots  (or  “experiments”) 

Define  incentives  for  pilot  participation 

Small  working  group  to  support  pilots 

Special  authorities  for  pilots 

Document  pilot  results 

Protect  and  support  the  pilots 

Communication,  Education,  and  Support 

Define  measures  of  success 

2-3  day  course  for  pilots  and  interested  others 
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Trial  Use-2 

Users  Group  (may  be  external,  i.e.  SPINs)  -  share 
experiences 

Transmit  lessons  learned  from  innovators  and  early 
adopters 

Case  exercise  for  transitioning  from  one  set  of  work 
practices  to  one  with  the  new  technology  support 

Technology  use  startup  and  coaching 

Identify  barriers  and  workarounds 
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Adoption 

Strong  set  of  incentives;  rewards  and  consequences 

Refined  guidance  on  CMMI®  usage  choices  and  implementation 

Education  -  mature  courses,  modularized  for  Just-In-Time 
delivery 

In-Process  Aids 

Repository  on  business  cases  and  lessons  learned 

Sample  implementation  plan  with  impact  analysis 

Job  aids  -  process  guides,  start-up  guides,  coaching,  JIT  training, 
guidebooks 

Identify,  draft  needed  policies  or  standards 

Ensure  that  CMMI®  sustainment  infrastructure  is  in  place  and 
resourced 
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Institutionalization 

Fully  realized  curriculum  of  training  for  different  types  of 
users 

New  employee  training/orientation 
Stability  in  leadership  use  of  CMMI®  data 
Grandfathering  vs.,  cutover  policy 

Continuous  improvement  to  adoption  artifacts  (guides,  etc.) 
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Adoption  Progress  Measurement 


You  can  use  the  concept  of  phased  transition  mechanisms 
to  help  build  a  “profile”  of  adoption  progress... 

•  Define  the  key  events  that  constitute  evidence  of 
movement  from  one  state  to  another 

•  Create  measures  that  allow  you  to  know  when  those 
events  have  occurred 

•  Gather  and  chart  the  measurements 

Example  that  follows  provides  “notional”  profiles  as  an 
organization  progresses  through  a  technology  adoption 
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Measuring  Diffusion  of  Process 
Improvements 


After  the  PI  kickoff 
meeting... 


Derived  from  Caputo,  CMM  Implementation  Guidelines 
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Getting  Awareness/Education 
Started... 
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Starting  to  work  with  pilots 
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Moving  out  beyond  the  pilots... 
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Starting  to  see 
institutionalization. . . 
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Moving  into  widespread  use... 


C/A 


s  CJ 


U  TU  A 
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Widespread  institutionalization 


The  “new”  improvement  is  now  the  status  quo! 
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Agenda 

Introduction/Expectation  Setting 

Why  TTP  is  Interested  in  CMMI®  Transition 

Seeing  CMMI®  as  a  Technology  Transition 

Applying  Technology  Transition  Concepts  to  CMMI®  Transition 

Building  a  Transition  Strategy  for  CMMI  ® 

Analyzing  Your  Existing  PI  Infrastructure  for  Potential  Reuse 
Summary/Where  Will  You  Go  From  Here? 


©  2002  by  Carnegie  Mellon  University 


Version  1.0 


page  72 


CctfiicgieMeilan 

Software  Engineering  Institute 

Building  a  Transition  Strategy  for 
CMMI® 

Key  Points: 

•  Understand  where  you’re  starting  from  in  terms  of  other  model- 
based  improvement  efforts 

•  Understand  your  audience  (both  “old”  and  “new”  if  starting  from 
another  model) 

-  Building  a  value  network  with  the  “EPG”  as  the  hub  is  a 
good  way  to  explore  this 

-  What’s  the  “fit”  of  CMMI®  with  your  key  audiences? 

•  Understand  WHY  you  are  transitioning 

-  What  problem  will  CMMI®  implementation  be  expected  to 
solve? 

•  Understand  your  desired/needed  pace  of  transition 

-  Use  adoption  progress  measurement  to  track 

•  Understand  what  you  can  leverage  from  previous  efforts 

-  We’ll  do  an  exercise  to  get  you  thinking  about  this! 
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Learning 
&  Adjusting 


Implementation 
&  Monitoring 


R 


T 


Adaptation 
&  Planning 


Readiness 
&  Fit  Determination 


Transition 

Management  Startup 


•TRAIL  can  provide  you  with 
ideas  on  practices/techniques 
to  use  to  develop  and 
implement  your  strategy 
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TRAIL 


Goals  for  Transition  Management 
Startup 


•  Problem  that  proposed  technology  is  meant  to 
solve  is  understood 


*  Common  transition  issues  are  understood 


•  Scope  &  goals  for  the  transition  are  defined 

•  Expectations  for  sponsorship  are  established 

•  Transition  infrastructure  needs  are  identified/ 
planned 


How  would  these  apply  to  CMMI? 
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TRAIL 

Goals  for  Readiness  &  Fit 
Determination 

•  “Maturity’Vreadiness  of  the  technology  is  understood 

•  Related  characteristics  of  the  intended  adopters  are 
understood 

•  Initial  adoption  risk  mitigation  actions  are  defined 


How  would  these  apply  to  CMMI? 
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TRAIL 

► 

— ► 

li  :i 

Goals  for  Adaptation  & 

▼ 

— ► 

0 

Planning 


•  Changes  needed  for  the  technology  &  adoption  contexts 
have  been  identified 

•  Transition  plan  and  measures  have  been  defined 

•  Transition  mechanisms  have  been  defined 


How  would  these  apply  to  CMMI? 
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TRAIL 

Goals  for  Implementation  & 
Monitoring 

•  Technology  implementation  events  are  defined 

•  Transition  mechanisms  are  available  for  use  in  the 
implementation 

•  Technology  is  successfully  implemented 

•  Progress  of  the  implementation  is  understood 

How  would  these  apply  to  CMMI? 
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TRAIL 


Goals  for  Learning  &  Adjustin 


•  Lessons  learned  from  implementations 
have  been  shared  with  the  relevant  community 


•  Transition  elements  have  been  updated 


How  would  these  apply  to  CMMI? 
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Transition  Management  Startup 
for  Organization  Moving  to  CMMI® 


Transition 
Management 
Startup 
Workshop 


Commitment  by  sponsors 
to  move  forward  with 
CMMI®  Adoption 


Transition  infrastructure 
established 
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Readiness  &  Fit  Determination  for 
Organization 


Planning/Readiness 

Analysis 


-Organization  Skills/ 
\  Knowledge  Gaps 
/  -Adoption  Risk 
/  Areas  Identified 
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Adaptation  &  Planning  for 
Adopting  Organization 

Build  Organizational  \ 

Transition  Plan  / 


Organization 
Ready  for  CMMI 
Adoption 


Develop  Organizational 
Transition  Mechanisms 
For  CMMI  / 
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Implementation  &  Monitoring  for 
Adopting  Organization 


Transition 
Implementation 
Planning 
w /  Orgn 


I 


..... 

Illllllllllll 


CMMI 
Training  for 
Adopters 


TTW-C 

Workshop 


•Workshops  later  in  the  implementation  cycle 
•“Applying”  transition  agent  skills  to  the 
implementation 


Organization 

Transition 

Checkup^ 
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Learning  &  Adjusting  for  Orgn 


r 

Transition 

Technology 

r 

Implementation 

Training  for 

Planning 

Adopters 

^  w /  Adopters  ^ 

V. 

TTWC 

Workshop 


Community 

Transition 

Checkup 


CMMI  Implementation 
Monitoring 


Share  Lessons 
Learned 


Using  the  transition  infrastructure  to  keep  things  “fresh” 
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Agenda 

Introduction/Expectation  Setting 

Why  TTP  is  Interested  in  CMMI®  Transition 

Seeing  CMMI®  as  a  Technology  Transition 

Applying  Technology  Transition  Concepts  to  CMMI®  Transition 

Building  a  Transition  Strategy  for  CMMI 

Analyzing  Your  Existing  PI  Infrastructure  for  Potential  Reuse 

Summary/Where  Will  You  Go  From  Here? 
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Stepping  onto  the  TRAII _ 

One  of  the  activities  in  TRAIL  is  to  define  transition 
mechanisms  for  your  technology — in  this  case,  CMMI 

-  Transition  mechanisms  are  a  way  of  helping  individuals 
and  groups  “move”  successfully  between  the  stages  of 
commitment  of  the  Patterson-Conner  curve  referred  to  in 
many  SEI  publications.... 

-  2  types:  communication  and  implementation  support 
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Communication  Mechanisms 

Primarily  focus  on  moving  between  Contact  Awareness,  and 
Awareness  Understanding 

CMMI®  Examples  from  1st  CMMI®  Tech  Transition  Check  Workshop: 

What  Works:  Contact  /  Awareness 

•  "Think  CMMI"  promotional  program;  reference  cards;  promotional 
materials  (14) 

•  Translations  of  SEI  Material  into  local  language  (8) 

•  Establish  multiple  communication  channels  (4) 

•  CMMI®  awareness  briefings/forums  (3) 

What  Works:  Understanding 

•  Self-assessment;  gap  analysis;  mini-assessments;  class  B  &  C 
assessments  that  relate  gaps  to  the  organization’s  processes  (20) 

•  Chart  on  how  processes  are  responsibility  of  different  roles/across 
organization  boundaries  (11) 

•  Poster  on  CMMI®  (7) 

•  Transition  Road  Map  (7) 

•  CMMI®  action  plans  (4) 

•  BoF  on  focused  topics  (4) 

-  Note:  cross-model  maps  didn't  get  many  votes! 
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Implementation  Support  Mechanisms 

Primarily  support  moving  from  Understanding  Trial  Use,  Trial  Use  Limited 
Adoption,  Limited  Adoption  Institutionalization 

Example  Implementation  Support  Mechanisms  from  TTC  Workshop  for 
CMMI: 

What  Works:  Trial  Use 

•  Integrating  QA  to  measure  PI  progress  (8) 

•  Link  QA  process  to  CMMI®  (8) 

•  Transition  Strategy  SW-CMM-->CMMI®  (8) 

•  Pilot/trials  in  non-development  areas  (7) 

•  Example  CMMI®  PI  budget  (5) 

What  Works:  Adoption 

•  Role-based  training  (24) 

•  Tailoring  guidance/strategies  for  different  organizational  Contexts  (23) 

•  Transition  steering  group  (10) 

•  ROI  trend  data  (9) 

•  Integrating  all  disciplines  into  the  process  group  (8) 

What  Works:  Institutionalization 

•  CMMI®  Best-Practice  Based  Templates/Checklists/Assets  (22) 

•  Integrating  Process  Review  into  Project  Management  Review  (14) 
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Miniature  “What’s  Worked” 
Exercise 

If  you’re  moving  from  an  existing  improvement  effort  to  CMMI,  you 
already  have  invested  a  significant  amount  of  time,  effort,  and  money  into 
building  transition  mechanisms  based  on  your  previous  model. 

•  Some  of  them  could  be  used  with  minimal  change  for  CMMI 

•  Some  of  them  would  take  a  good  bit  of  rework  to  be  useful 

•  Some  aren’t  worth  trying  to  “save”  -  you’re  better  off  starting  from 
scratch 

Think  about  the  mechanisms  you’ve  successfully  used  with  your  previous 
improvement  effort 

Using  the  table  on  the  following  slide  as  a  guide,  spend  10  minutes  listing 
mechanisms  you  might  think  about  reusing  for  CMMI 

Write  any  you  think  would  be  particularly  useful  to  the  group  on  a  sticky 
note  and  post  on  the  flip  chart 

After  individual  work,  we’ll  look  at  the  table  and  discuss  its  implications 
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What’s  Worked/How  Much  It  Will 
Take  to  Reuse 
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What  do  you  do  with  the  results? 

Use  results  of  analysis  to  estimate  (at  least  some)  of  the 
resource  needs  for  moving  from  one  model-based 
improvement  to  another 

•  It’s  typical  to  assume  ‘everything’  can  be  reused, 
however  a  little  thought  often  leads  to  a  different 
conclusion 

•  Different  people  will  have  different  ideas  about  level  of 
reuse  achievable  highlighting  those  differences  can 
help  you  to  refine  your  ideas 

•  How  mechanisms  were  architected  the  first  time  around 
sometimes  determines  how  easy  they  are  to  reuse 

•  Giving  sponsors  “data-based”  estimates  helps  them  to 
see  you’re  “walking  your  talk” 

•  Results  of  this  analysis  feed  into  “readiness/fit”  and 
“adaptation/planning”  stages  of  TRAIL 
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Agenda 

Introduction/Expectation  Setting 

Why  TTP  is  Interested  in  CMMI®  Transition 

Seeing  CMMI®  as  a  Technology  Transition 

Applying  Technology  Transition  Concepts  to  CMMI®  Transition 

Building  a  Transition  Strategy  for  CMMI 

Analyzing  Your  Existing  PI  Infrastructure  for  Potential  Reuse 

SummarylWhere  Will  You  Go  From  Here? 
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Summary-1 

Looking  at  CMMI®  from  a  “TRAIL”  viewpoint  rather  than  a 
traditional  PI  viewpoint 

•  Is  easier  for  some  people 

•  Is  compatible  with  most  process  improvement  approaches, 
but  looks  at  some  elements  differently 

Watch  the  CMMI®  and  TTP  websites  for  other 
ideas/techniques  for  supporting  CMMI®  implementation 

Participate  in  the  CMMI®  User’s  Forum  and  other  mechanisms 
provided  by  the  SEI  and  provide  feedback  on  “what’s  worked, 
what’s  needed”  for  YOUR  CMMI®  implementation  context! 
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Summary-2 

CMMI®  is  early  in  its  maturation/transition  life  cycle.  That  means: 

•  those  who  adopt  CMMI®  will  have  to  build  most  of  the 
implementation  mechanisms 

•  there  is  little  "hard  data"  on  successful/unsuccessful  strategies 
for  its  use 

•  there  is  no  "ROI"  data  that  a  CFO  would  find  credible  (yet!) 

As  an  early  adopter  of  CMMI,  you  need  to  be  prepared  to  "fill  in 
the  gaps" 

•  understand  and  be  prepared  to  invest  in  creating  the  transition 
mechanisms  your  organization  will  need  to  be  successful 

•  there  won't  be  as  much  reuse  of  SW-CMM®  materials  as 
you'd  like  or  hope! 


©  2002  by  Carnegie  Mellon  University 


Version  1.0 


page  94 


CarnegieMellon 

Software  Engineering  Institute 

Summary-3 

•  build  your  internal  case  study  from  the  beginning--what/how 
you  did  it 

•  put  your  baseline  measurements  in  place  from  the 
beginning--so  you  can  have  your  own  ROI  data  sooner 
rather  than  later! 

Basic  data  to  collect  if  you  don't  already: 

•  defects  released  to  the  field  within  1  st  year  of 
operation; 

•  #  of  defects  detected  prior  to  release  via  review/testing; 

•  total  program  schedule,  effort,  cost  (planned  vs. 
actual),  plus  total  schedule,  effort,  cost  for  software 
subsystems  and  for  systems  engineering  function 

•  Consider  using  TRAIL  to  help  formulate,  communicate, 
implement  your  CMMI  transition  strategy 

Give  us  feedback  on  how  it  works  -  TRAIL  is  still  in 
development! 
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Information  Resources 

The  following  resource  list  for  CMMI®  and  systems  engineering 
was  compiled  by  Beth  Gramoy  of  the  Navy's  SEPO/SPAWAR: 

Web  sites 

•  Software  Engineering  Institute  (SEI) 

-  http://www.sei.cmu.edu/sei-home.html  or 

-  http://www.sei.cmu.edu/cmmi/  for  CMMI®  specific  info 

•  International  Committee  on  Systems  Engineering  (INCOSE) 

-  http://www.incose.org/ 

•  Defense  Systems  Management  College,  Systems  Engineering 
Management  Department 

-  http://www.dsmc.dsm.mil/educdept/se%5Fdept.htm 

•  NASA  Systems  Engineering 

-  http://sed.gsfc.nasa.g0v/V/visi0n.html 
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Information  Resources-2 

•  NASA  Software  Engineering  Lab 

-  http://sel.gsfc.nasa.gov/ 

•  MITRE  Systems  Engineering  Process  Office 

-  http://www.mitre.org/resources/centers/sepo/ 

•  Headquarters  Standard  Systems  Group,  located  at  Maxwell 
Air  Force  Base-Gunter  Annex, 

-  http://web1  .ssg.gunter.af.mil/sep/SEP/menus/main.asp?.5 
456115580168115/ 

•  DoD  Software  Information  Clearinghouse,  Defense  Analysis 
Center 

-  http://www.dacs.dtic.mil/ 

Documents 

•  Systems  Engineering  Fundamentals,  Defense  Systems 
Management  College  Press,  Dec  99 

-  http://www.dsmc.dsm.miI/educdept/se%5Fdept.htm#SE 
Fund 
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Information  Resources-3 

•  Univ  of  Ariz  &  Sandia  Lab:  What  is  Systems  Engineering 

-  http://www.sie.arizona.edu/sysengr/whatis/index.html 

•  INCOSE  Systems  Engineering  Journal 

-  http://www3.interscience.wiley.com/cgi-bin/jtoc?ID=39084 

•  INCOSE  Systems  Engineering  Handbook 

-  http://www.incose.org/pubslist.html  INCOSE  Systems 
Engineering 

•  INCOSE  Metrics  Primer 

-  http://www.incose.org/pubslist.html  INCOSE  Systems 
Engineering 

•  DoD  Guide  to  Integrated  Product  and  Process  Development 

-  http://www.acq.osd.mil/te/survey/table_of_contents.html 

•  NASA  Systems  Engineering  Handbook 

-  http://sed.gsfc.nasa.g0v/R/Res-Guidelines.html 


©  2002  by  Carnegie  Mellon  University 


Version  1.0 


page  100 


CctfiicgieMeilon 

Software  Engineering  Institute 

Information  Resources-4 

Tools 

•  INCOSE  Tools  Database  working  group 

-  http://www.incose.org/tools/index.html 

•  SE  Tool  Surveys 

-  Requirements  Management  Tools  Survey 

-  Systems  Architecture  Tools  Survey 

-  Measurement  Tools  Survey 

-  Vendors  who  have  responded  to  previous  surveys 

•  SE  Tool  Databases 

-  Tools  Database  by  Name 

-  Tools  Database  by  Vendor 

•  SE  Tools  by  Taxonomy 

-  Tools  Database  by  IMPIG  Taxonomy 

-  Tools  Database  by  EIA-632  Taxonomy  (tools  categorized 
by  EIA-632  requirement) 

-  Tools  Database  by  IEEE-1220  Taxonomy 
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Information  Resources-5 

•  NASA  Tool  Inventory  -  Goddard  Space  Flight  Center 

-  http://joy.gsfc.nasa.gov/MSEE/mseehome.htm 
Standards 

•  EIA-632  Processes  for  Engineering  a  System,  Dec 
1998 

-  http://global.ihs.com/ 

•  EIA/IS-731  Systems  Engineering  Capability  Model,  Dec 
1998  (being  phased  out  in  favor  of  CMMI) 

-  http://global.ihs.com/ 


©  2002  by  Carnegie  Mellon  University 


Version  1.0 


page  102 


CctfiicgieMeilan 

Software  Engineering  Institute 

Information  Resources-6 

•  Capability  Maturity  Model  Integration  -  Systems 
Engineering/Software  Engineering,  VI. 02,  4  Dec 2000 

-  http://www.sei.cmu.edu/cmmi/products/models.html 

•  IEEE  1220  Application  and  Management  of  the 
Systems  Engineering  Process,  1998 

-  http://shop.ieee.orq/store/HelpDesk/standards.as 

•  IEEE/EIA  12207  Software  Life  Cycle  Processes 

-  SSC  San  Diego  PAL: 

http://sepo.spawar.navy.mil/sepo/Standards.html 
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Information  Resources-7 

•  Bodies  of  Knowledge 

-  Engineering  Management  Book  of  Knowledge 
(EMBOK) 

-  IEEE  Engineering  Mgmt  Society  project 

-  Project  Management  Institute  (PMI)  Management 
Book  of  Knowledge  (PMBOK) 

-  http ://www.pmi. org/publictn/pmboktoc .htm 

-  Guide  to  the  Software  Engineering  Body  of 
Knowledge  (SWBOK) 

-  http://www.SWEBOK.org/ 
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